home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group98c.txt / 000032_icon-group-sender _Wed Sep 16 08:38:15 1998.msg < prev    next >
Internet Message Format  |  2000-09-20  |  4KB
  1. Return-Path: <icon-group-sender>
  2. Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239])
  3.     by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id IAA21918
  4.     for <icon-group-addresses@baskerville.CS.Arizona.EDU>; Wed, 16 Sep 1998 08:38:12 -0700 (MST)
  5. Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM)
  6.     id AA03742; Wed, 16 Sep 1998 08:37:43 -0700
  7. Message-Id: <35FF1A94.66F1@gte.net>
  8. Date: Tue, 15 Sep 1998 20:55:32 -0500
  9. From: MJE <evans@gte.net>
  10. Reply-To: evans@gte.net
  11. Organization: None
  12. X-Mailer: Mozilla 3.01 (Win95; I)
  13. Mime-Version: 1.0
  14. To: icon-group@optima.CS.Arizona.EDU
  15. Subject: Re: Context Switching
  16. References: <199809152057.NAA09001@varda.premenos.com>
  17. Content-Type: text/plain; charset=us-ascii
  18. Content-Transfer-Encoding: 7bit
  19. Content-Transfer-Encoding: 7bit
  20. Content-Transfer-Encoding: 7bit
  21. Errors-To: icon-group-errors@optima.CS.Arizona.EDU
  22. Content-Transfer-Encoding: 7bit
  23. Status: RO
  24.  
  25. If you want a language that can do a lot more than C, then why rely all
  26. the time on C conventions, instead of making your own?
  27.  
  28. Icon is wonderful with strings because the strings are not C strings,
  29. they are Icon objects.  Analogy:  Icon can be wonderful with stacks,
  30. because the stacks are not C stacks, but Icon stacks.
  31.  
  32. Icon has complete control of how it handles functions, coexpressions,
  33. recursion, and so on, there is no mandatory requirement that they all be
  34. treated as C function calls.  Icon doesn't have to put parameters on a
  35. stack, it can put them on the heap and "context-switch" by switching
  36. data pointers to blocks on the heap.  You could implement several
  37. "stack" structures right on the heap, instead of relying on the system
  38. stack.
  39.  
  40. Those heap-based stacks would handle all the issues involved in
  41. context-switching, without resorting to fancy thread systems.
  42.  
  43. Built-in operators and functions can easily be rewritten to assume that
  44. their stack exists elsewhere.  I.e., as C calls, they take no input
  45. parameters, but instead lookup a global pointer that gives them their
  46. current stack somewhere on the heap, then they take parameters from
  47. that.
  48.  
  49. Or, rather than rewriting the builtins, you just wrap them with
  50. "handlers" that know about these things and put the right parameters
  51. into the standard C function calls.  So, none of the built-ins change,
  52. but you add "handlers" to baby-sit them with respect to the switching
  53. stacks.
  54.  
  55. The idea of "fooling" the Icon executable, and doing so in a way that is
  56. non-portable, assembler-based, and buggy, and that will break with every
  57. vendor's compiler release, is what I dislike.
  58.  
  59. I just wanted to share these ideas.  Maybe I haven't really knocked down
  60. your points, but that's OK, we share ideas here.
  61.  
  62. Mark
  63.  
  64.  
  65.  
  66.  
  67.  
  68.  
  69. Ken Walker wrote:
  70. > 
  71. > > From evans@gte.net Tue Sep 15 12:45:59 1998
  72. > >
  73. > > Thanks, but I think you missed my point.  The hidden assumption here is
  74. > > that Icon function calls shall behave exactly like C function calls.  I
  75. > > am trying to say that, with auxiliary data structures, the job might be
  76. > > done without threads.
  77. > 
  78. > That is a good point. On the other hand the Icon runtime system is
  79. > currently written in C and makes use of the C stack. There can be
  80. > "suspended" C frames on stack when a context switch occurs. The changes
  81. > needed to perform a co-expression context switch without doing a C-level
  82. > context switch would be significant in the interpreter and some of
  83. > the runtime system might end up looking rather ugly. It would be
  84. > even more work in the compiler; the compiler converts Icon code into
  85. > C code. Would such a change be worth making it a little easier to
  86. > port co-expressions?
  87. > 
  88. > Ken Walker, kenneth.walker@sfo.harbinger.com
  89. > Harbinger Coporation, Concord, Ca. 94520
  90.  
  91.  
  92. Clinton Jeffery wrote:
  93. > 
  94. > Mark,
  95. > 
  96. > > I think you missed my point.  The hidden assumption here is that Icon
  97. > > function calls shall behave exactly like C function calls.  I am trying to
  98. > > say that, with auxiliary data structures, the job might be done without
  99. > > threads.
  100. > 
  101. > Co-expressions include the state of suspended built-in operators and
  102. > functions, which *are* implemented by C functions.  If generators and
  103. > "suspend" were only allowed from Icon source code to Icon source code,
  104. > then I think you would be right about this, but since they include
  105. > suspended C functions, I am afraid we have to swap the C stack.
  106. > 
  107. > Clint
  108.  
  109.